home *** CD-ROM | disk | FTP | other *** search
/ ftp.cs.arizona.edu / ftp.cs.arizona.edu.tar / ftp.cs.arizona.edu / icon / newsgrp / group98a.txt / 000080_icon-group-sender _Mon Mar 2 16:43:13 1998.msg < prev    next >
Internet Message Format  |  2000-09-20  |  3KB
  1. Return-Path: <icon-group-sender>
  2. Received: from kingfisher.CS.Arizona.EDU (kingfisher.CS.Arizona.EDU [192.12.69.239])
  3.     by baskerville.CS.Arizona.EDU (8.8.7/8.8.7) with SMTP id QAA01578
  4.     for <icon-group-addresses@baskerville.CS.Arizona.EDU>; Mon, 2 Mar 1998 16:43:12 -0700 (MST)
  5. Received: by kingfisher.CS.Arizona.EDU (5.65v4.0/1.1.8.2/08Nov94-0446PM)
  6.     id AA03768; Mon, 2 Mar 1998 16:43:11 -0700
  7. Date: Mon, 2 Mar 1998 22:11:43 +0300 (MEST)
  8. From: Ehud Lamm <mslamm@mscc.huji.ac.il>
  9. To: icon-group@optima.CS.Arizona.EDU
  10. Subject: Optimzing Icon
  11. Message-Id: <Pine.A32.3.91.980302215824.39794B-100000@pluto.mscc.huji.ac.il>
  12. Mime-Version: 1.0
  13. Content-Type: TEXT/PLAIN; charset=US-ASCII
  14. Errors-To: icon-group-errors@optima.CS.Arizona.EDU
  15. Status: RO
  16. Content-Length: 2352
  17.  
  18. The recent thread about compiling Icon into C raised the question of 
  19. optimizing the resulting C code. 
  20.  
  21. The are two aspect worth thinking about here:
  22. 1. What Icon programs and constructs are more efficient (from a 
  23. computer's standpoint. NOT programmer time). 
  24. 2. How should you implement, in the best possible way, an Icon construct 
  25. in C (or machine language for that matter).
  26.  
  27. Question 1, refers to things like type usage (less conversions are good, 
  28. regardless of interpretation or compilation of the program), use of good 
  29. data structures (and using them consistently as lists/queue etc.), good 
  30. use of string scanning and things of this sort.
  31.  
  32. These aspects are crucial if you paln to produce an optimizing compiler, 
  33. because knowing which constructs are better allows you to optimize their 
  34. use to good machine level code. It also allows you to perform some 
  35. check/transformations at the front end of the compiler.
  36.  
  37. Question 2, is less Icon dependent, and more C-oriented or specific to 
  38. the machine targeted. It is based on the fact that in order to produce 
  39. good code, you have to know what kinds of operations are fast, and by how 
  40. much. Good (==fast) low level code relies on understanding the cost of 
  41. operations.
  42.  
  43. When you write a translator to C you have to be good at C... For 
  44. exampleit is common to note that the strlen function in C is not fast, 
  45. since it has to scan the entire string in order to find its length. This 
  46. is becasuse the way C handles strings (as null terminated vectors of 
  47. characters). It is a well known tip that if you process a C  string in 
  48. a loop you should strlen at each iteration, but rather keep a local 
  49. variable with the length (obtained by strlen outside the loop), and 
  50. upadate when you update the string. 
  51.  
  52. This common technique for example, is something to keep in mind when you 
  53. translate a string dominated program to C. 
  54.  
  55. Of course you have other options (like coding you own string hanlding 
  56. libray. An option with obvious drawbacks), which may not be directly 
  57. relevent to the Icnon->C compiler. But this is just an example. There 
  58. are dozens of such optimizations possible. 
  59.  
  60. An optimzing compiler can not find you a better algorithm, to solve your 
  61. problem - but it will usually produce better low level code. This is a 
  62. well known truth...    
  63.  
  64.  
  65.  Ehud Lamm     mslamm@pluto.mscc.huji.ac.il
  66.  
  67.